Packet-based networking protocols, such as Internet protocol (IP), commonly include sequence numbers within the packets. Sequence numbers are used to by the receiving side to reassemble received packets into the correct order and which make it possible for the receiving side to detect and request retransmission of dropped packets. A flow of related packets is herein referred to as a session. Example sessions include data transmissions, such as a file transfer, downloading of multimedia, such as a streaming video, two-way communication using voice over IP (VoIP), and so on. Each session may have its own distinct sequence of numbers. A group of flows or sessions is herein referred to as a stream.
Some types of network testing equipment test a network or test particular nodes on the network by generating network traffic, i.e., packets, sending the generated traffic to the device under test (DUT), receiving packets from the DUT, and analyzing the results to determine, for example, the DUT's latency, throughput, ability to handle malformed packets, and so on. It is desirable for network test equipment to be able to emulate traffic from many different sources and many different sessions simultaneously. This requires the ability to generate and maintain separate sequence numbers for each of the various sources and sessions being emulated. A conventional approach to maintaining separate sequence numbers is to store current values of a particular sequence number in memory, e.g., using a variable in software. This approach is illustrated in FIG. 1.
FIG. 1 is a flow chart showing a conventional method of generating sequence numbers by using variables that are stored in memory. At step 100, memory is allocated for a variable used to store the next sequence value. In the embodiment illustrated in FIG. 1, the variable is named “SEQ”. For example, a location in DRAM memory might be reserved to store this variable. At step 102, the variable named SEQ is initialized, e.g., SEQ is set to a starting value. This involves writing this value to the memory location that has been allocated for storing SEQ. The process then moves to step 104, which waits until the value of SEQ is needed. For example, during traffic generation, when the test equipment generates the next packet in the session, the process goes to step 106, in which the memory location is read to get the current value of SEQ, and then to step 108, where the current value of SEQ is inserted into or included in the header of the packet being generated. The completed packet is eventually sent out, i.e., transmitted to its intended destination over the network.
At step 110, the value of SEQ is incremented and stored, which means that the updated value of SEQ is written to the memory location allocated for storing SEQ, and the flow chart returns to step 104, where it waits for the next time that SEQ is needed. The read-modify-write operation described in steps 106, 108, and 110 must be performed every time the variable SEQ is used and incremented. Although this may not seem like a significant amount of overhead, the cumulative performance cost of this overhead increases with the number of packets generated by the test equipment per unit time. For test equipment that generates a large rate of traffic, particularly where the test equipment emulates large numbers of sources and/or sessions, this overhead becomes burdensome and may even cause a system bottleneck that constrains the overall performance of the test equipment itself.
Another conventional method is to use a counter output as the source for sequence numbers, where each packet contains a sequence number that is equal to the next counter value. This method has the disadvantage that only simple sequences may be generated. Such systems are not flexible enough to generate complex or arbitrary sequences. A further disadvantage to the conventional systems described above is that each uses only one method, e.g., simple counter systems do not perform read-modify-write operations and vice-versa.
Accordingly, in light of these disadvantages associated with conventional approaches to generating sequence numbers, there exists a need for data generation with low-overhead, selectable, and flexible sequence number generation.